-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Implementation: #[feature(sync_nonpoison)]
, #[feature(nonpoison_mutex)]
#144022
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
b45b493
to
deda5c5
Compare
This comment has been minimized.
This comment has been minimized.
deda5c5
to
19b1a2c
Compare
This comment has been minimized.
This comment has been minimized.
19b1a2c
to
a259232
Compare
This comment has been minimized.
This comment has been minimized.
e130930
to
804d305
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reviewers: since this is a large file, it might be good to compare this directly with the poison::mutex
module.
(for copy paste)
delta library/std/src/sync/poison/mutex.rs library/std/src/sync/nonpoison/mutex.rs
diff library/std/src/sync/poison/mutex.rs library/std/src/sync/nonpoison/mutex.rs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The git diff here is somewhat unfortunate, as I had to reorder the tests for things to make sense. All of the "duplicated" tests here are taken from the existing tests in the file, so there is technically nothing new here other than the macro.
I would ideally like to write some more tests (testing more panic behavior in nonpoison
, better tests for the replace
drop behavior), but this is already quite a large PR. (Also the panic behavior is already in the doc test)
804d305
to
b615348
Compare
r? tgross35 |
c5133bf
to
f633b62
Compare
Commits squashed from pull 134663.
This commit brings the `mutex.rs` file more in line with the current `poison/mutex.rs` file. Additionally, it ensures that all items are marked with `#[unstable(feature = "nonpoison_mutex", issue = "134645")]`. Some features that are currently unstable on nightly also have the "nonpoison_mutex" feature, but they have their correct feature gates commented out above. Not all of the current nightly features are implemented here, and that will happen in a later commit. Note that this commit will likely not pass CI.
This commit moves the duplicating test macro for poison and nonpoison locks into the parent module. Since it is generic for all locks (either it calls `unwrap` or it doesn't), we can use it for all poison/nonpoison lock tests.
f633b62
to
35fc4df
Compare
Continuation of #134663
Tracking Issue: #134645
This PR implements a new
sync/nonpoison
module, as well as thenonpoison
variant of theMutex
lock.There are 2 main changes here, the first is the new
nonpoison::mutex
module, and the second is themutex
integration tests.For the
nonpoison::mutex
module, I did my best to align it with the current state of thepoison::mutex
module. This means that several unstable features (mapped_lock_guards
,lock_value_accessors
, andmutex_data_ptr
) are also in the newnonpoison::mutex
module, under their respective feature gates. Everything else in that file is under the correct feature gate (#[unstable(feature = "nonpoison_mutex", issue = "134645")]
).Everything in the
nonpoison::mutex
file is essentially identical in spirit, as we are simply removing the error case from the originalpoison::mutex
.The second big change is in the integration tests. I created a macro called that allows us to duplicate tests that are "generic" over the different mutex types, in that the poison mutex is always
unwrap
ped.I think that there is an argument against doing this, as it can make the tests a bit harder to understand (and language server capabilities are weaker within macros), but I think the benefit of code deduplication here is worth it. Note that it is definitely possible to generalize this (with a few tweaks) to testing the other
nonpoison
locks when they eventually get implemented, but I'll leave that for a later discussion.